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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the security architecture for the H(e)NB subsystem. This includes security requirements 
on Home Node Bs, Home eNode Bs, and other H(e)NB-associated network nodes (e.g. SeGW and H(e)MS), as well as 
the procedures and features which are provided to meet those requirements. 
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for Advanced Networking (TISPAN); NGN functional architecture; Network Attachment Sub- 
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[21] 3GPP TS 33.401: "3GPP System Architecture Evolution (SAE): Security architecture". 

[22] IETF RFC 2560: "X.509 Internet Public Key Infrastructure OnUne Certificate Status Protocol - 

OCSP" 

[23] Open Mobile Alliance OMA-WAP-OCSP VI .0: "Online Certificate Status Protocol Mobile 

Profile". URL: http://www.openmobilealliance.or.g/ 

[24] IETF RFC 4806: "Online Certificate Status Protocol (OCSP) Extensions to IKEv2". 

[25] Void. 

[26] IETF RFC 5280: "Internet X.509 PubUc Key Infrastructure Certificate and Certificate Revocation 

List (CRL) Profile". 

[27] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2". 

[28] 3GPP TS 25.367: "Mobility procedures for Home Node B (HNB); Overall description; Stage 2". 

[29] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[30] 3GPP TS 23.401 : "General Packet Radio Service (GPRS) enhancements for Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN) access". 

[31] 3GPP TS 22.220: "Technical Specification Group Services and System Aspects; Service 

requirements for Home Node B (HNB) and Home eNode B (HeNB)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

CSG: A closed subscriber group identifies subscribers of an operator who are permitted to access one or more cells of 
the PLMN of but having restricted access ('CSG cells') 

Hosting party: The party hosting the H(e)NB and having a contract with the PLMN operator. 

Security Gateway: Element at the edge of an operator"s security domain terminating security association(s) for the 
backhaul link between H(e)NB and network. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

AAA Authentication, Authorization, and Accounting 

ACL Access Control List 

ACS Auto-Configuration Server 

AKA Authentication and Key Agreement 

CA Certification Authority 

CPE Customer Premises Equipment 

CRL Certificate Revocation List 

CSG Closed Subscriber Group 

DNS Domain Name System 

DPD Dead Peer Detection 

eNB Evolved Node-B 

EAP Extensible Authentication Protocol 
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ESP Encapsulating Security Payload 

E-UTRAN Evolved UTRAN 

FQDN Fully Qualified Domain Name 

GNSS Global Navigation Satellite System 

H(e)NB Home NodeB or Home eNodeB 

H(e)NB-GW Home (e)NodeB Gateway 

H(e)MS Home NodeB Management or Home eNodeB Management System 

HeMS Home eNodeB Management System 

HeNB Home eNodeB 

HMS Home NodeB Management System 

HNB Home NodeB 

HP Hosting Party 

HPM HP Module 

HW Hardware 

IKE Internet Key Exchange 

IMSI International Mobile Subscriber Identity 

L-GW Local Gateway 

LIPA Local IP Access 

LTE Long Term Evolution 

MME Mobility Management Entity 

MSK Master Session Key 

NAPT Network Address Port Translation 

NAT Network Address Translation 

NAT-T NAT-Traversal 

OCSP Online Certificate Status Protocol 

PKI Public Key Infrastructure 

SA Security Association 

SeGW Security Gateway 

SGSN Serving GPRS Support Node 

S-GW Serving Gateway 

TLS Transport Layer Security 

TrE Trusted Environment 

UDP User Datagram Protocol 

UICC Universal Integrated Circuit Card 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

USIM Universal Subscriber Identity Module 

UMTS Universal Mobile Telecommunications System 

UTRAN Universal TeiTestrial Radio Access Network 

WAP Wireless Application Protocol 



4 Overview of Security Architecture and Requirements 

4.1 System architecture of H(e)NB 




H(e)MS 
Figure 4.1.1 : System Architecture of l-l(e)NB 
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Description of the system architecture: 

Air interface between UE and H(e)NB should be backwards compatible to the air interface in UTRAN or E- 
UTRAN. 

H(e)NB accesses the operator"s security domain via a Security Gateway (SeGW). The backhaul between 
H(e)NB and SeGW may be insecure. 

Security Gateway represents the operator"s core network with respect to performing mutual authentication with 
the H(e)NB. 

AAA server authenticates the hosting party based on the authentication information retrieved from HSS when 
hosting party authentication is performed. 

Security tunnel is established between H(e)NB and Security Gateway to protect information transmitted in 
backhaul link. 

HNB-GW performs mandatory UE access control and HNB performs optional UE access control in the case of 
non-CSG capable UEs or non-CSG capable HNBs. SeGW and HNB-GW are logically separate entities within 
operator"s network, with the SeGW located in front of the HNB-GW. The SeGW may be integrated into the 
HNB-GW. If the SeGW and the HNB-GW are not integrated, then the interface between the HNB-GW and the 
SeGW may be protected using NDS/IP as specified in TS 33.210 [9]. The interface between HNB-GW and 
MSC/SGSN may be protected using NDS/IP. 

HeNB-GW is optional to deploy. When HeNB-GW is not deployed, the SeGW is located at the edge of the core 
network and the interface between SeGW and MME/S-GW may be protected using NDS/IP as specified in 
TS 33.210 [9]. When HeNB-GW is deployed, then SeGW and HeNB-GW are logically separate entities, with 
the SeGW located in front of the HeNB-GW. The SeGW may be integrated into HeNB-GW. If the SeGW and 
the HeNB-GW are not integrated, then the interface between the HeNB-GW and the SeGW may be protected 
using NDS/IP, the interface between HeNB-GW and MME/S-GW may be protected using NDS/IP. 

- HMS as specified in TS 32.583 [2] and/or HNB-GW as specified in TS 25.467 [12] performs location 
verification of HNB. 

HeMS as specified in TS 32.593 [11] performs location verification of HeNB. 

Secure communication is required to H(e)NB Management System (H(e)MS). 

L-GW is optional to deploy. If L-GW is deployed, then the secured interface between H(e)NB and Security 
Gateway is used by the L-GW to communicate with the core network. 

4.2 Network Elements 
4.2.1 H(e)NB 

The H(e)NB is a network element that connects User Equipment via its radio interface to the operator" s core network. 
The backhaul link to the operator"s network is a broadband connection. A H(e)NB is typically deployed in customers" 
premises. 

NOTE: The term H(e)NB refers to both Home NodeB (HNB) and Home eNodeB (HeNB), when both are meant 
without distinction. 



4.2.2 Security Gateway (SeGW) 



The SeGW is a network element at the border of a security domain of the operator. If a H(e)NB-GW is deployed the 
SeGW is located in front of the H(e)NB-GW, else it is located at the edge of the core network. After successful mutual 
authentication between the H(e)NB and the SeGW, the SeGW connects the H(e)NB to the operator"s security domain. 
Any connection between the H(e)NB and the H(e)NB-GW or core network is tunnelled through the SeGW. 
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4.2.3 H(e)NB Management System (H(e)MS) 

The H(e)MS is a management server that configures the H(e)NB according to the operator"s policy. H(e)MS is also 
capable of installing software updates on the H(e)NB. The H(e)MS server may be located inside the operator"s access 
or core network (accessible on the MNO Intranet) or outside of it (accessible on the public Internet). 

The HMS is specified in TS 32.583 [2]. 

The HeMS is specified in TS 32.593 [11]. 

4.2.4 UE 

UE is a standard user equipment for UMTS (for HNB) or LTE (for HeNB). 

4.2.5 H(e)NB Gateway (H(e)NB-GW) and MME 

HNB-GW is specified in TS 25.467 [12] and HeNB-GW is specified in TS 36.300 [27]. 

4.2.6 AAA Server and HSS 

HSS stores the subscription data and authentication information of the H(e)NBs. When hosting party authentication is 
required, AAA server authenticates the hosting party based on the authentication information retrieved from HSS. 

4.2.7 Void 

4.2.8 Local Gateway (L-GW) 

L-GW is specified in TS 23.060 [29] and in TS 23.401 [30]. The Local IP Access (LIP A) is achieved using a L-GW 
colocated with the H(e)NB. The L-GW is connected to the Serving Gateway (S-GW) or to the SGSN via the SeGW. 

4.3 Interfaces (Reference Points) 

4.3.1 Backhaul Link 

The backhaul link used between H(e)NB and SeGW provides a secure tunnel carrying both the user plane data and the 
control plane data that are transmitted between the H(e)NB and the H(e)NB-GW or network elements in the core 
network. 

NOTE: If LIPA is activated, the secured backhaul link between the H(e)NB and SeGW is used by the L-GW to 
communicate with the core network. 

H(e)MS traffic is also tunnelled through this secure backhaul link, if the H(e)MS is accessible on the MNO Intranet. 

The backhaul link may also carry other data between H(e)NB and operator"s radio access or core network, e.g. time 
protocol traffic. 

4.3.2 H(e)MS Interface 

The H(e)MS Interface between the H(e)NB and the H(e)MS server shall provide a secure connection carrying 
configuration data., SW updates and additional data, e.g. location information. 

4.3.3 Interface between SeGW and AAA Server, AAA Server and HSS 

The interface between the SeGW and AAA Server provides a secure connection carrying authentication, authorization, 
and related information. 
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The interface between AAA Server and HSS provides a secure connection for the retrieval of authentication vectors 
(e.g. for hosting party authentication) and retrieval of H(e)NB access-related information for HPM. 

4.3.4 Interface between H(e)NBs 

The interface used between two HNBs or between two HeNBs provides a direct link carrying both the user plane data 
and the control plane data. The interface is specified as lurh interface between two HNBs (cf. TS 25.467 [12]) and as 
X2 interface between two HeNBs (cf. TS 36.300 [27]). It is used during handover between the two base stations 
connected by this link. 

NOTE: This clause handles the direct connection between two network elements. If the messages between two 
network elements are routed via the core network using the existing backhaul links to the SeGW(s), then 
a direct link in the sense of this clause is not necessary. 

4.4 Security Requirements and Principles 

4.4.1 Operation 

The requirements on operation are: 

Only algorithms of adequate cryptographic strength shall be used for authentication and protection of 
confidentiality and integrity. 

Modifications of Hosting Party controlled information by the operator shall only be allowed with the permission 
of the Hosting Party. 

The extent of Hosting Party controllable information shall be controlled by the operator. 

- IMSIs of UEs connected to H(e)NB shall not be revealed to the Hosting Party of the H(e)NB. 

4.4.2 Requirements on H(e)NB 

The requirements on the H(e)NB are: 

The integrity of the H(e)NB shall be validated before any connection to the H(e)NB-GW or into the core 
network is established. 

The H(e)NB shall be authenticated by the SeGW based on a globally unique and permanent H(e)NB identity. If 
the H(e)NB was enrolled to an operator PKI according to clause 8.5 of the present document, then the H(e)NB 
may alternatively be authenticated by the SeGW based on the identity provided by the operator. 

- The H(e)NB shall authenticate the SeGW based on SeGW certificate. 

Optionally the hosting party of the H(e)NB may be authenticated by the SeGW in cooperation with the AAA 
server using EAP-AKA as specified in RFC 4187 [3]. 

If hosting party authentication is used, the H(e)NB shall shut down its air interface and disconnect from the 
operator"s core network on removal of the HPM which was used for authentication towards the MNO. 

The H(e)NB may support the establishment of direct links to other base stations (i.e. HNB to HNB and HeNB to 
HeNB) as specified in clause 4.3.4. If establishment of direct links is supported the H(e)NB shall support 
enrolment to the operator PKI as specified in clause 8.5. Once the H(e)NB is enrolled to the operator PKI, it shall 
use the operator device certificate. The usage of operator PKI enrolment shall be securely configurable. If the 
default configuration is set in the factory it shall be set to no usage of operator PKI enrolment. 

NOTE: Setting the default configuration to no usage of PKI enrolment allows for H(e)NBs to be deployed in 

networks containing H(e)NBs with or without support of PKI enrolment.. On the other hand this requires 
e.g. a connection to initial H(e)MS based on authentication using the vendor certificate to securely switch 
the H(e)NB to enroll to the operator PKI, and to provide the operator root certificate as specified in clause 
8.5.2. 
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If a direct link to another base station secured by security procedures as specified in clause 4.4.8 is established, 
the H(e)NB shall authenticate the other base station based on the identity provided by the operator to the other 
base station. 

If a direct link to another base station secured by security procedures as specified in clause 4.4.8 is established, 
the H(e)NB shall be authenticated by the other base station based on the identity provided by the operator to the 
H(e)NB. 

The H(e)NB shall establish direct links with other base stations only after establishment of the backhaul link. If 
the backhaul link is terminated, then also all direct links to other base stations shall be terminated. 

The H(e)NB shall authenticate the H(e)MS, if the H(e)MS is accessed on the public Internet. 

The H(e)NB shall be authenticated by the H(e)MS using the same identity as for authentication to the SeGW, if 
the H(e)MS is accessed on the public Internet. 

The configuration and the software of the H(e)NB shall only be updated in a secure way, i.e. the integrity of the 
configuration data including the licensed radio parameters and the integrity of the software updates must be 
verified. 

Sensitive data including cryptographic keys, authentication credentials, user information, user plane data and 
control plane data shall not be accessible at the H(e)NB in plaintext to unauthorized access. 

The time base of the H(e)NB shall be synchronized to the core network. 

The location of the H(e)NB shall be reliably transferred to the network. 

The H(e)NB shall be capable of filtering unauthenticated traffic received from the access network. Operator 
policy shall control which types of unauthenticated traffic are filtered. 

The H(e)NB shall implement a mechanism to shut down the air interface within a certain time period after the 
connection between H(e)NB and the rest of the operator network went out of service. This time period and the 
usage of the mechanism shall be configurable by the operator. 

The H(e)NB shall only activate its air interface after successful establishment of the backhaul link (cf. sub-clause 
4.4.5 of the present document). The establishment of the backhaul link happens as a result of successful integrity 
validation, device mutual authentication between H(e)NB and SeGW, and optional hosting party authentication 

All security requirements of the eNB secure environment of TS 33.401 [21] clause 5.3 shall apply to the HeNB. 
Security measures to establish this secure environment shall be assured by the TrE (subclause 5.1.2) where they 
fall under the capability of the TrE. 

4.4.3 Requirements on SeGW 

The requirements on the SeGW are: 

The SeGW shall be authenticated by the H(e)NB using a SeGW certificate. The SeGW certificate shall be signed 
by a CA trusted by the operator. 

- The SeGW shall authenticate the H(e)NB based on H(e)NB certificate. 

The SeGW may authenticate the hosting party of the H(e)NB in cooperation with the AAA server using EAP- 
AKA as specified in RFC 4187 [3]. 

The SeGW shall allow the H(e)NB access to the H(e)NB-GW or core network only after successful completion 
of all required authentications. 

Any unauthenticated traffic from the H(e)NB shall be filtered out at the SeGW. 

4.4.4 Requirements on H(e)MS 

The requirements on the H(e)MS are: 
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The H(e)MS shall be authenticated by the H(e)NB if the H(e)MS is accessible on the public Internet and may be 
authenticated by H(e)NB if the H(e)MS is accessible on the MNO Intranet using a H(e)MS certificate. The 
H(e)MS certificate shall be provided by a MNO trusted CA. 

The H(e)MS shall authenticate the identity of the H(e)NB if the H(e)MS is accessible on the public Internet and 
may authenticate the identity of the H(e)NB if the H(e)MS is accessible on the MNO Intranet, using a H(e)NB 
certificate. This identity shall be the same as used during backhaul link establishment (cf. sub-clause 4.4.5 of the 
present document). 

The H(e)MS may securely configure the H(e)NB according to the operator" s policy, whether or not to use IPsec 
for subsequent connections (cf. clause 4.4.5 of the present document). 

If the H(e)MS is accessible on the MNO Intranet and the mutual authentication between H(e)MS and H(e)NB is 
not performed the identity of H(e)NB has to be transferred over the H(e)MS link. 

NOTE 1 : In case of H(e)MS accessible on the MNO intranet there may be an additional secure end-to-end tunnel 
between H(e)NB and H(e)MS carried inside the secure backhaul link. 

NOTE 2: Mutual authentication between H(e)MS and H(e)NB may not be necessary if the H(e)NB is connected to 
the H(e)MS through the SeGW and mutual authentication between H(e)NB and SeGW has taken place. 

4.4.5 Requirements on Backhaul Link 

The requirements on the backhaul link are: 

The establishment of the secure backhaul link shall be based on IKEv2 as specified in TS 33.310 [7] comprising 
the required authentications as given in subclauses 4.4.2 and 4.4.3 of the present document. 

The backhaul link shall provide integrity, confidentiality and replay protection of the transmitted data. 

IPsec use for the backhaul link is mandatory to implement but optional to use based on an operator policy. To 
allow for such operator policy, the H(e)NB may be configurable to IPsec or non-IPsec usage option. If this 
configuration is supported, the default configuration set in the factory shall be the usage of IPsec. Based on 
operator policy, the H(e)MS may securely configure the H(e)NB, whether or not to use IPsec for subsequent 
connections. If the operator chooses not to use IPsec, mutual authentication between the H(e)NB device and the 
SeGW shall be performed and the interface between the H(e)NB and SeGW shall be secured with a mechanism 
that provides layer 2 security for confidentiality and integrity protection of communications. This mechanism 
then shall also bind this secure communications to device authentication between H(e)NB and SeGW and 
optional HPM authentication. 

The security solution for the backhaul link shall be based on IPsec ESP tunnel mode as specified in TS 33.210 
[9]. If the H(e)NB is configurable not to use IPsec, in addition a suitable layer 2 protection mechanism shall be 
mandatory to support. If the H(e)NB is configured not to use IPsec, this layer 2 mechanism shall be used for the 
backhaul link protection. 

NOTE: For the non-IPsec usage option the details of the authentication mechanism, the layer 2 security 
mechanism and the binding are out of scope of the present document. 

Any connection between the H(e)NB/L-GW and the H(e)NB-GW or core network shall be tunnelled through the 
Backhaul Link. 

The security solution for the backhaul link shall be compatible with common network address and port 
translation variations and support firewall traversal. 

4.4.6 Requirements on H(e)MS Link 

The requirements on the H(e)MS link are: 

The establishment of the secure H(e)MS link shall be based on the authentication principles as given in 
subclauses 4.4.2 and 4.4.4 of the present document. 

The H(e)MS link shall provide integrity, confidentiality and replay protection of the transmitted data between 
H(e)MS and H(e)NB. 
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4.4.7 Requirements on Local Gateway (L-GW) 

From security point of view, the Local Gateway (L-GW) shall be an optional element. The L-GW shall be tightly 
integrated with the H(e)NB, and share the same security requirements with the H(e)NB. 

The requirements on the L-GW are: 

The L-GW shall use the same secure backhaul link established by the H(e)NB as specified in subclause 4.4.5 of 
the present document. 

The L-GW shall use the same secure H(e)MS link established by the H(e)NB as specified in subclause 4.4.6 of 
the present document. 

- If the network allocated different IP addresses (remote, i.e. inner) to the L-GW and H(e)NB, then the secure 
backhaul link established by the H(e)NB shall carry traffic to and from both these addresses. 

The L-GW shall be integrated into the security architecture of the H(e)NB, in particular: 

- the L-GW shall be included in the device integrity check according to clause 6. 1 of the present document; 

- the L-GW shall be included in the device validation according to clauses 7.1 and 8.3.2.2 of the present 

document. 

4.4.8 Requirements on tine Direct Link between H(e)NBs 

The support of direct links between two H(e)NBs as specified in clause 4.3.4 is optional. 

The requirements on this direct link between base stations shall follow the requirements for the backhaul link as given 
in clause 4.4.5 with the following additions: 

The provisions for the non-IPsec usage option given in clause 4.4.5 shall not apply. 

Usage of the security procedures with IKEv2/IPsec on the direct links is optional and shall be securely 
configurable by the operator. 

NOTE 1 : The above requirement implies that the actual enrolment to the operator PKI is not necessary if the 
security procedures with IKEv2 and IPsec are not used. 

If the security procedures with IKEv2/IPsec are used, the H(e)NBs shall be enrolled to the operator PKI. 

Both H(e)NBs shall authorize the establishment of a direct link. If security procedures with IKEv2/IPsec are 
used, this authorization is accomplished by the validation of the operator-provided device certificates against the 
operator root certificate. If security procedures with IKEv2/IPsec are not used, the mechanism for this 
authorization is out of scope of the present document. 

NOTE 2: If security procedures with IKEv2/IPsec are not used, the authorization can be achieved e.g. by 
administrative measures like using Virtual LAN configurations. 

NOTE 3: If security procedures with IKEv2/IPsec are used, H(e)NBs can perform authorization step in addition to 
certificate validation, e.g., authorization based on white/black list configured in H(e)NBs. The 
authorization mechanism is out of the scope of the present document. 

4.4.9 Requirements on Verification of H(e)NB Identity and Operating 
Access Mode 

The requirements on the H(e)NB identity and operating access mode verification in the network are: 

The network shall implement a verification that the identity used by the H(e)NB for communicating with the 
network is either the same identity that is used for authenticating to the SeGW or an identity related to this 
authenticated identity. In case the H(e)NB uses a related identity to communicate with the network, that related 
H(e)NB identity shall have a secure mapping to the identity that is used for authenticating to the SeGW. The 
above verification shall be implemented in the H(e)NB-GW. If a HeNB-GW is not deployed, an MME 
implementing the above verification shall be deployed. 
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NOTEO: The above requirement implies that the network has to ensure that all communication of H(e)NBs is 
subject to the above verification, even if a (rogue) message from a compromised H(e)NB would not 
indicate to originate from a H(e)NB. This could e.g. be the case if a compromised HeNB pretends to be 
an eNB in some messages. 

The network shall implement a verification that the H(e)NB is allowed to operate in the access mode (i.e. closed, 
hybrid or open mode) indicated by the H(e)NB. The above verification shall be implemented in the H(e)NB- 
GW. If a HeNB-GW is not deployed, the above verification shall be implemented in the MME. 

For all H(e)NBs operating in closed access mode, the above verifications should be applied. 

NOTEl: (void) 

N0TE2: If the H(e)NB has been compromised and the above verifications are not performed, the UE access 

control functions in clause 5.4 are assumed to be unreliable. If the above verifications are performed, the 
UE access control functions in clause 5.4 are assumed to be reliable even in the presence of a 
compromised H(e)NB. 



5 Security Features 

5.1 Secure Storage and Execution 

5.1 .1 Hosting Party Module 

The Hosting Party authentication shall be based on a Hosting Party Module. The Hosting Party Module (HPM) is a 
physical entity distinct from the H(e)NB physical equipment, dedicated to the identification and authentication of the 
Hosting Party towards the MNO. The HPM shall have the following features: 

The HPM shall be a tamper resistant environment and shall contain the credentials used to authenticate the 
Hosting Party. 

The HPM shall be bound to the Hosting Party (e.g. by contractual agreement between Hosting Party and MNO) 
and supplied by the MNO to the Hosting Party. 

The HPM shall be removable from the H(e)NB and it shall be possible for a Hosting Party to change the 
H(e)NB device by inserting the HPM in the new H(e)NB. 

The HPM is provided by means of a UICC. 

5.1 .2 Trusted Environment (TrE) 
5.1.2.1 General 

The Trusted Environment (TrE) shall be a logical entity which provides a trustworthy environment for the execution of 
sensitive functions and the storage of sensitive data. 

All data produced through execution of functions within the TrE shall be unknowable to unauthorized external entities. 

The TrE shall be built from an irremovable, HW -based root of trust by way of a secure boot process, which shall occur 
whenever a H(e)NB is turned on or goes through a hard reset. The root of trust shall be physically bound to the H(e)NB. 
The secure boot process shall include checks of the integrity of the TrE performed by the root of trust. Only 
successfully verified components shall be loaded or started. The TrE , after having been successfully started, shall 
proceed to verify other components of the H(e)NB (e.g. operating system and further programs) that are necessary for 
trusted operation of the H(e)NB. 

The TrE shall perform sensitive functions (such as storing private keys and providing cryptographic calculations using 
those private keys) needed to perform H(e)NB device integrity check (cf clause 6.1) and device validation as 
specifically described in clauses 7.1 and 8.3.2.2. 
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The TrE shall perform sensitive functions (such as storing private keys and providing cryptographic calculations using 
those private keys ) needed for H(e)NB device authentication with the operator network, as specifically described in 
clauses 7.2 and 8.3. 

5.2 Device Mutual Authentication 

This clause specifies the device mutual authentication between H(e)NB and SeGW. 

The device mutual authentication is mandatory for H(e)NB. 

Device mutual authentication shall be performed using certificates. The H(e)NB"s credentials and critical security 
functions for device authentication shall be protected inside a TrE. 

The device mutual authentication shall be securely bound to device integrity validation. This procedure, when 
successful, leads to mutual authentication between the H(e)NB and the SeGW. 

The certificate-based device authentication shall have the following parts: 

The H(e)NB shall be provisioned with a device certificate. This device certificate allows the authentication of the 
H(e)NB by the SeGW (and thus the operator network). The device certificate shall be provided by a CA trusted 
by the operator, e.g. the CA of the operator, the manufacturer or the vendor of the H(e)NB, or by another party 
trusted by the operator. 

The SeGW shall be configured with a certificate. This certificate allows the authentication of the SeGW by 
H(e)NB. The certificate shall be provided by an operator trusted CA. 

A Fully Qualified Domain Name (FQDN) formatted identifier shall be used for certificate based authentication 
of the H(e)NB and of the SeGW. For the H(e)NB this FQDN shall be globally unique for device certificates 
provided by the vendor. If no DNS is available for resolution of the FQDN of the SeGW, then the IP address of 
SeGW shall be used as identifier. 

The H(e)NB may check the revocation status of certificates using OCSP. 

The SeGW may check the revocation status of certificates using CRLs or OCSP. 

5.3 Hosting Party IVIutual Authentication 

The hosting party mutual authentication is optionally performed by the operator" s network following successful device 
mutual authentication between H(e)NB and SeGW. 

An EAP-AKA based method [3] shall be used for hosting party authentication. When Hosting Party Authentication is 
used, both device and hosting party authentication must be completed successfully before a secure tunnel to the operator 
network can be established. 

The authentication of the hosting party is based on credentials contained in a separate Hosting Party Module (HPM) in 
H(e)NB, and in the MNO HLR/HSS. 

The EAP-AKA based hosting party authentication shall have the following parts: 

- An AKA credential shall be stored in HPM enabling to use EAP-AKA. The SeGW is acting as EAP 

authenticator and forwards the EAP protocol messages to the AAA server to retrieve an authentication vector 
from AuC via HSS/HLR. 

A globally unique identifier in the format of an IMSI shall be used for EAP-AKA based authentication. These 
IMSIs shall be marked in HLR/HSS as used for H(e)NBs, e.g. by allocating dedicated ranges or by adding 
specific attributes to avoid misuse of these IMSIs for ordinary UEs. 

NOTE: The implementation of the related HLR/HSS entry is out of scope of the present document. 

5.4 Other security features 

The communication between time server and H(e)NB shall be provided with adequate protection. 
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In case of non-CSG-capable UEs or non-CSG-capable HNBs, UE access control shall be performed in the HNB-GW 
and optionally in HNB. UE access control per HNB operating in closed access mode, as specified in TS 22.220 [31], 
shall be applied in the HNB-GW to all UE associated messages (e.g. RANAP). 

In case of CSG capable UEs and CSG capable HNBs, UE access control shall be performed in the SGSN/MSC as 
specified in TS 25.467 [12]. UE access control per HNB operating in closed access mode shall be applied in the 
SGSN/MSC to all UE associated messages (e.g. RANAP). 

In the case of HeNBs, UE access control shall be performed in the MME as specified in TS 36.300 [27]. UE access 
control per HeNB operating in closed access mode shall be applied in the MME to all UE associated messages (e.g. 
SlAP). 

The H(e)NB-GW shall verify that all UE associated messages from H(e)NBs operating in closed access mode, as 
specified in TS 22.220 [31], can be mapped to a specific CSG id and that this CSG id is allowed for the identity of the 
originating H(e)NB (cf clause 4.4.9). In the absence of a HeNB-GW, the MME shall perform this CSG id verification. 

NOTE 1: The CSG id being verified may be explicitly present in the message as an information element or may be 
mapped by other means. 

NOTE la: The above requirement implies that the network has to ensure that all UE-associated messages from 

H(e)NBs operating in closed access mode are subject to the above verification, even if a (rogue) message 
from a compromised H(e)NB would not indicate to originate from a H(e)NB. 

The HMS and/or HNB-GW shall perform HNB location verification. The HeMS shall perform HeNB location 

verification. 

NOTE 2: Location verification is needed to satisfy various security, regulatory and operational requirements of 
operators. 
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6 Security Procedures in H(e)NB 

6.1 Device Integrity Check 

6.1 .1 Device Integrity Check Procedure 

The H(e)NB and TrE shall perform a device integrity check upon booting and before connecting to the H(e)NB-GW, 
core network and/or to the H(e)MS. The device integrity check shall be based on one or more trusted reference 
value(s) and the TrE. The following requirements shall apply: 

The TrE shall boot securely according to clause 5.1.2.1. 

The integrity of a component is verified by comparing the result of a measurement (typically a cryptographic 
hash) of the component to the trusted reference value. If these values agree, the component is successfully 
verified and can be started. 

- For each of the component integrity checks, the TrE shall retrieve the corresponding trusted reference value from 
secure memory. 

- The TrE shall check the integrity of all components necessary for trusted operation of the device. Any individual 
component shall be started only if its integrity check is successful. 

The integrity of the device is verified if all components necessary for trusted operation of the device are verified. 

6.1 .2 Protection of Trusted Reference Value(s) 

- The TrE shall securely store all trusted reference values at all times. 

The TrE shall detect un-authorized modifications of the trusted reference values necessary for trusted operation 
of the device. 

6.2 Void 

6.3 Measures for Clock Protection 

6.3.1 Clock Synchronization Security Mechanisms for H(e)NB 

The H(e)NB requires time synchronization with a time server. The H(e)NB shall support receiving time 
synchronisation messages over the secure backhaul link between H(e)NB and the SeGW. 

Optionally other secure clock servers may be used, which do not use the secure backhaul link. In this case the 
communication between these clock server(s) and H(e)NB shall be secured. 

NOTE 1 : How to secure communication between clock servers and H(e)NB outside the secure backhaul link is out 
of scope of the present document. 

The availability of the correct current time is important for certificate validation and thus for the establishment of secure 
links (IKEv2 and/or TLS). This results in the following requirements: 

The H(e)NB shall be equipped with a clock. 

Upon the H(e)NB connecting to the CN, the clock shall be synchronized with the secured time server. 

During normal operation of the H(e)NB, the clock shall be re-synchronized with the secured time signal from the 
network at least every 48 hours. 
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The following requirements on local time arise from certificate handling, applying to operation of the H(e)NB before 
the secure backhaul link or the secure H(e)MS connection is established and thus before secured clock information is 
available from the clock server: 

The last time at which the H(e)NB was active before the current power-up shall be recorded and saved in the 
TrE. 

Upon restoration of power of the H(e)NB, the clock shall resume counting from the last saved time. If a 
continuously running clock exists, the clock may resume counting from the later of the current time of the clock 
and the last saved time 

NOTE 2: Usage of the current time of the clock upon restoration of power of the H(e)NB assumes that the clock 

starts at its own power-up at some point in time which does not lie in the future. The start time could be at 
a fixed date, e.g. the epoch 1970-01-01. Otherwise the H(e)NB may falsely interpret a certificate as 
expired, if the start time of the clock lies after expiry time of the certificates. 

NOTE 3: If a HeNB clock erroneously received a time lying sufficiently far in the future, the validation of the 

SeGW's or the H(e)MS"s certificate will fail and the H(e)NB will be unable to connect to the operator"s 
network. No specific solution to this scenario is given; a common solution for problems with the 
H(e)NB authentication might be considered in the future. 



7 Security Procedures between H(e)NB and SeGW 

7.1 Device Validation 

The H(e)NB shall support a device validation method where the device implicitly indicates its validity to the SeGW or 
H(e)MS by successful execution of device authentication. To achieve this, the following requirement applies: 

If the device integrity check according to clause 6.1 failed, the TrE shall not give access to the sensitive 
functions using the private key needed for H(e)NB device authentication with the SeGW. 

The CA issuing the H(e)NB device certificate need to be trusted by the manufacturer or vendor of the H(e)NB, 
whoever of both is responsible for the device integrity of the H(e)NB. 

NOTE 1: This trust in the CA issuing the device certificate is in addition to the requirements given in clause 5.2. 

NOTE 2: If the H(e)NB is enrolled to an operator PKI, and the operator device certificate is used during 

authentication, then also such successful authentication towards SeGW or other network elements 
includes the indication of successful device validation. This transitive trust is possible, as the enrolment 
takes place based on the vendor device certificate. This transition of trust must be considered by the 
operator. 

7.2 Device Authentication 
7.2.1 General 

Device authentication of the H(e)NB shall be securely bound by the TrE to the device validation of the H(e)NB 
platform. 

Device authentication of H(e)NB shall be based on device certificate for H(e)NB and network certificate for the core. 

IKEv2 with certificates used for authentication shall be run between H(e)NB and SeGW to mutually authenticate the 
H(e)NB and the SeGW. If the H(e)NB is configurable not to use IPsec, then an appropriate authentication mechanism 
for mutual authentication of H(e)NB and SeGW shall be mandatory to support. If the H(e)NB is configured not to use 
IPsec, then this authentication mechanism shall be used between H(e)NB and SeGW to mutually authenticate the 
H(e)NB and the SeGW. The detailed authentication procedure is out of scope of the present document. 
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7.2.2 SeGW and Device Mutual Authentication Procedure 

Device authentication shall be performed using IKEv2 with public key signature based authentication with certificates, 
as specified in TS 33.310 [7]. The H(e)NB device shall authenticate itself to the SeGW with a certificate based on the 
globally unique and permanent H(e)NB identity, signed by an operator authorized entity, or alternatively based on the 
operator-provided device identity in case the H(e)NB is enrolled to the operator PKI. The SeGW shall authenticate itself 
to the H(e)NB using a certificate signed by an operator trusted CA. The H(e)NB shall verify the SeGW identity by 
checking the subjectAltName field of the SeGW certificate against the name of the SeGW used by the H(e)NB to 
connect to the SeGW. 

NOTE 1: If DNS is available, the SeGW's name is the FQDN used to resolve its IP address; otherwise it is the IP 
address of the SeGW. 

The H(e)NB may check the revocation status of the SeGW certificate using OCSP as specified in RFC 2560 [22] and 
OMA-WAP-OCSP [23] with the exception that the SHA-1 and SHA-256 hash functions shall be mandatory to support. 
For security reasons, the use of SHA-1 is not recommended for newly created OCSP responses. If the profile in OMA- 
WAP-OCSP [23] is used, support for WAP specific protocols is not required, and the provisions on certificates and 
signatures given in TS 33.310 [7], clause 6.1, shall be followed. 

NOTE la: It is likely that in a future 3GPP release, OCSP responses which use SHA-1 as the hash algorithm will be 
prohibited. 

Support for OCSP is optional for the operator network. The H(e)NB should support OCSP. 

NOTE 2: It is strongly recommended to support OCSP in the H(e)NB, as this feature may become mandatory for 
H(e)NB in future releases. 

The OCSP communication between H(e)NB and OCSP server may use the in-band signaling of certificate revocation 
status in IKEv2 according to RFC 4806 [24], through which the SeGW can include an OCSP response within IKEv2. 
Support for this extension to IKEv2 in H(e)NB and SeGW is optional. 

The SeGW may check the revocation status of the H(e)NB certificate using CRLs according to TS 33.310 [7] or OCSP 
as specified in RFC 2560 [22] and OMA-WAP-OCSP [23] with the exception that the SHA-1 and SHA-256 hash 
functions shall be mandatory to support. For security reasons, the use of SHA-1 is not recommended for newly created 
CRLs and OCSP responses. If the profile in OMA-WAP-OCSP [23] is used, support for WAP specific protocols is not 
required, and the provisions on certificates and signatures given in TS 33.310 [7], clause 6.1, shall be followed. 

NOTE 2a: It is likely that in a future 3GPP release, CRLs and OCSP responses which use SHA-1 as the hash 
algorithm will be prohibited. 

NOTE 2b: Methods for securely updating the device certificate remotely are handled in the present document only 
for the case when enrolment to an operator PKI is supported and used. If it is not possible to update the 
device certificate, the certificate lifetime needs to exceed the expected lifetime of the H(e)NB. 

The SeGW shall implement support for either CRL checking or OCSP or both. The locations of the CRL Server and 
OCSP Responder may be in the operator's network or provided by the manufacturer/vendor. Neither the operator nor 
the manufacturer is required to provide a CRL Server or an OCSP Responder. For the case when the operator provides 
a CRL Server or OCSP Responder, the manufacturer shall forward revocation data to the operator. The interface to 
forward revocation data is out of scope of the present document. 

If the H(e)NB certificate contains CRL or OCSP server information (cf. sub-clause 7.2.5.2), then the SeGW may 
contact this server for revocation information. 

NOTE 3: A CRL or OCSP server located at manufacturer of H(e)NB allows distribution of revocation information 
by the manufacturer directly. To use such revocation information, normally the SeGW needs a CRL or 
OCSP client capable to reach the public Internet to contact these servers. 

Validity check of H(e)NB certificates in SeGW shall be configurable by the operator, i.e. whether to use CRLs, OCSP 
or both and whether to use operator CRL or OCSP server, manufacturer CRL or OCSP server, or more than one of 
them. 

The H(e)NB"s TrE shall be used to provide the following critical security functions supporting the IKEv2 and 
certificate processes:. 

The H(e)NB"s identity shall be stored in the TrE and shall not be modifiable. 



£75/ 



3GPP TS 33.320 version 1 1 .6.0 Release 1 1 21 ETSI TS 1 33 320 V1 1 .6.0 (201 2-1 1 ) 

The H(e)NB"s private key shall be stored in the TrE and shall not be exposed outside of the TrE. 

The root certificate used to verify the signatures on the SeGW certificate shall be stored in the H(e)NB"s TrE 
and shall be writable by authorized access only. The verification process for signatures shall be performed by the 
H(e)NB"s TrE. 

The H(e)NB"s TrE shall be used to compute the AUTH payload used during the IKE_AUTH request message 
exchanges. 

NOTE 4: Autonomous validation is performed during secure start-up and performs validation of the H(e)NB. As 
IKEv2 allows the inclusion of information data into Notify Payload, information regarding the 
trustworthy state of the H(e)NB may be carried in the Notify Payload (see Annex A.l) during IKEv2 
procedures from the H(e)NB to the SeGW. Notify Payload within IKEv2's IKE_AUTH message is 
protected by IKEv2 SK and AUTH. In addition, the Notify Payload, as constructed by the TrE, should 
include a nonce and should be cryptographically signed by the TrE. 

7.2.3 H(e)NB/IKEv2 Processing Requirements for SeGW Certificates 

The H(e)NB/IKEv2 processing requirements for SeGW certificates shall be as follows: 

1. The SeGW shall not send certificate paths containing more than four certificates. 

2. The H(e)NB shall be able to process SeGW certificate paths containing up to four certificates. The SeGW 

certificate and the intermediate CA certificates for the SeGW shall be obtained from the IKEv2 CERT payload. 
The certificates of the trusted root CA shall be obtained from the TrE of the H(e)NB. 

3. The H(e)NB shall check the validity time of the SeGW certificates, and reject certificates that are either not yet 

valid or that are expired. 

4. In case the H(e)NB is configured to check the certificate revocation status of the SeGW certificate, and it 
receives no valid OCSP response, the H(e)NB shall abort the IKEv2 protocol. 

NOTE 1 : The execution of this check does not depend on the existence of an OCSP server information in the 
SeGW certificate, if OCSP extension according to RFC 4806 [24] is used. 

NOTE 2: A H(e)NB may want to check the revocation status of the SeGW certificate, but it may not have access to 
the OCSP server until the IPSec tunnel is established. In this case, after the tunnel is established and 
before user data is transmitted in the tunnel, the H(e)NB sends an OCSP request message to the OCSP 
responder. When the H(e)NB receives the OCSP response, it checks the certificate status. If the certificate 
of SeGW is valid, the H(e)NB will allow user data to be transmitted to the SeGW in the tunnel. If the 
certificate is not valid, the H(e)NB may terminate the tunnel that just was established. 

7.2.4 SeGW/IKEv2 Processing Requirements for H(e)NB Certificates 

The SeGW/IKEv2 processing requirements for H(e)NB certificates shall be as follows: 

1 . The H(e)NB shall not send certificate paths containing more than four certificates. 

2. The SeGW shall be able to process H(e)NB certificate paths containing up to four certificates. The H(e)NB 

certificate and the intermediate CA certificates for the H(e)NB shall be obtained from the IKEv2 CERT payload. 
The trusted root CA shall be obtained from a SeGW local store of trusted CA certificates. 

3. The SeGW shall check the validity time of the H(e)NB certificates, and reject certificates that are either not yet 

valid or that are expired. 

4. The SeGW shall check the certificate revocation status if configured by local policy. 

NOTE: The mere existence of a CRL or OCSP server information in the H(e)NB certificate does not mandate the 
SeGW to perform certificate status checking. 
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7.2.5 Security Profiles 

7.2.5.1 Profile for I KEv2 

The H(e)NB and the SeGW shall conform to the profile of IKEv2 as specified in clause 5.4.2 of TS 33.210 [9] with the 
exception that the use of pre-shared secrets for authentication is not supported. 

The following additional requirements on certificate based IKEv2 authentication for the IKE_INIT_SA and 
IKE_AUTH exchanges shall be applied: 

The use of RS A signatures for authentication shall be supported. 

The H(e)NB shall include its identity in the IDi payload of the first IKE_AUTH request. 

The H(e)NB identity in the IDi payload may be used for policy checks. 

Initiating/responding end entities are required to send certificate requests in the IKE_INIT_SA exchange for the 
responder and in the IKE_AUTH exchange for the initiator. 

The messages for the IKE_AUTH exchanges shall include a certificate or certificate chain providing evidence 
that the key used to compute a digital signature belongs to the identity in the ID payload. 

The certificates in the certificate payload shall be encoded as type 4 (X.509 Certificate - Signature). 

7.2.5.2 IKEv2 Certificate Profile 

7.2.5.2.1 IKEv2 Entity Certificates 

The H(e)NB and SeGW certificates shall both conform to the requirements set out in clauses 6.1.1 and 6.1.3 of TS 
33.310 [7] with the following additions and exceptions: 

The H(e)NB certificate shall be signed by an entity that is authorized by the operator, e.g. the manufacturer or 
the vendor. In addition, the entity signing the H(e)NB certificate shall be authorized by the manufacturer or 
vendor. 

The H(e)NB certificate shall carry the HNB unique identity in FQDN format, as specified in TS 23.003 [8], in 
the subjectAltName. This identity shall be the same as the identity in the IDi payload of the first IKE_AUTH 
request. 

If the manufacturer or vendor provides a CRL or OCSP server, the H(e)NB certificate shall carry the CRL 
distribution point as specified in TS 33.310 [7] or the OCSP server information (AIA extension) as specified in 
RFC5280 [26] and RFC 2560 [22]. 

NOTE: Server information for CRL and/or OCSP servers deployed in operator network may be configured in 
SeGW. 

If the operator provides an OCSP server, the SeGW certificate shall carry the OCSP server information as 
specified in RFC 2560 [22]. This OCSP server information is not mandatory, if OCSP extension according to 
RFC 4806 [24] is used. 

If the H(e)NB is enrolled to an operator PKI, the H(e)NB certificate issued by the operator CA and the H(e)NB 
device identity assigned by the operator may follow clause 6.1.3b of TS 33.310 [7] without additions and 
exceptions. 

7.2.5.2.2 IKEv2 CA Certificates 

IKEv2 CA certificates shall conform to the requirements set out for NE CA certificates in clauses 6.1.1, and 6.1.4b of 
TS 33.310 [7]. 

NOTE: This requirement implies that there is no restriction in the issuer name for both H(e)NB CA certificates 
and SeGW CA certificates. 
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7.3 Hosting Party Authentication 



Device Authentication of the H(e)NB by the SeGW may optionally be followed with an EAP-AKA-based hosting party 
authentication exchange. The IKEv2 certificate-based mutual authentication is executed according to clause 7.2 of the 
present document, extended by IKEv2"s multiple authentication procedure defined in IETF RFC 4739 [6]. 

The IKEv2 EAP-AKA authentication shall follow the TS 33.234 [10] specification. 

The H(e)NB"s HPM shall be used to provide critical security functions supporting the EAP-AKA authentication 
processes. 

The secret key (K) used for HP authentication shall be stored in the HPM. 

The HPM is responsible for computing the RES and AUTN parameters for the EAP-AKA based hosting party 
authentication. 

7.4 IPsec Tunnel Establishment 

If the H(e)NB only supports usage of IPsec, or if it is configured to use IPsec tunnel between the H(e)NB and the 
SeGW, the following procedure shall be performed. 

The H(e)NB shall use IKEv2 protocol to set up at least one IPsec tunnel to protect the traffic with SeGW, i.e. a pair of 
unidirectional SAs between H(e)NB and SeGW. All signalling, user, and management plane traffic over the interface 
between H(e)NB and SeGW shall be sent through an IPsec ESP tunnel (with NAT-T UDP encapsulation as necessary) 
that is established as a result of the authentication procedure. 

The H(e)NB shall initiate the creation of the S A i.e. it shall act as initiator in the Traffic Selector negotiation. Upon 
H(e)NB"s request, the SeGW should allocate IP address (remote, i.e. inner) to the H(e)NB after successful 
authentication. If LIPA is activated, SeGW may allocate a different remote (i.e. inner) IP address to the L-GW than the 
remote (i.e. inner) IP address allocated to the H(e)NB. 

NOTE: If the SeGW allocates different remote IP addresses to the H(e)NB and the L-GW, then the H(e)NB can 
retrieve both IP addresses (remote, i.e. inner) via the IKEv2 CFG payload, the H(e)NB can retrieve its 
own IP address (remote, i.e. inner) via the IKEv2 CFG payload and the L-GW IP address directly via the 
IPsec tunnel (e.g. using DHCP or OAM), or the H(e)NB can retrieve only the L-GW IP address via the 
IKEv2 CFG payload and the H(e)NB address directly via the IPsec tunnel (e.g. using DHCP or OAM). In 
order to avoid any IP address misconfiguration between the entities within the H(e)NB, the IP address 
allocating entity can provide information about the IP address allocation and the H(e)NB implementation 
can use the information to differentiate the IP addresses assigned and then configure the H(e)NB and L- 
GW addresses appropriately. 

The H(e)NB and SeGW shall use the IKEv2 mechanisms for detection of NAT, UDP encapsulation for NAT Traversal, 
H(e)NB initiated NAT keep-alive, IKEv2 SA and IPsec SA rekeying, and Dead Peer Detection (DPD). 

During setup of the tunnel, the H(e)NB shall include a list of supported ESP authentication transforms and ESP 
encryption transforms as part of the IKEv2 signalling. The SeGW shall select an ESP authentication transform and an 
ESP encryption transform conforming to clause 5.3 of TS 33.210 [9], and shall signal this to the H(e)NB. 

If the H(e)NB is configured not to use IPsec, an appropriate layer 2 protection mechanism that satisfies the requirements 
as described in clause 4.4.5 shall be used. 



7.5 Device Authorization 



Optionally an AAA server may be used to verify the authorization of the H(e)NB to connect to the operator" s network 
based on the authenticated device identity extracted from the H(e)NB certificate. This authorization check is separate 
from and in addition to the revocation status check via OCSP or CRL. 
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NOTE: If OCSP is used, the result of the authorization check may be included in the certificate revocation check 
described in section 7.2.2 by having the OCSP responder provide a certificate status of 'good' as in RFC 
2560 [22] only when the certificate has not been revoked and the device is authorized to connect to the 
operator"s network. If either of these conditions is false, the OCSP responder should provide a certificate 
status of "revoked". 
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8 Security Aspects of H(e)NB Management 

8.1 Location Verification 

8.1.1 General 

Operators require assurance of the H(e)NB location to satisfy various security, regulatory and operational requirements. 
The H(e)MS and/or HNB-GW (referred to in this section as the 'verifying node') shall perform location verification. 
One or more types of location information of H(e)NB may be optionally stored in the verifying node by operators for 
location verification. It shall be possible for the verifying node to obtain one or more of the following information 
which may be used to perform location verification: 

the public IP address of the broadband access device provided by the H(e)NB 

the IP address and/or access line location identifier provided by broadband access provider 

information of macro-cells surrounding the H(e)NB provided by the H(e)NB 

geo-coordinates provided by a GNSS receiver embedded into the H(e)NB 

Different deployment scenarios and H(e)NB configurations will influence the availability, accuracy and reliability of 
these types of location information. 

8.1 .2 IP Address provided by H(e)NB 

A H(e)NB is normally connected to the IP network via some access device (e.g. DSL modem, cable modem, home 
router, etc.). If the H(e)NB is capable of acquiring the public IP address of the access device, it shall be able to provide 
this IP address to the verifying node. 

8.1 .3 IP Address and/or access line location identifier provided by 
broadband access provider 

A H(e)NB is normally connected to the IP network via some access device (e.g. DSL modem, cable modem, home 
router, etc.) This device will have an IP address and/or access line location assigned by the broadband access provider. 
The broadband access provider may, subject to regulatory approval, be able to provide the verifying node with this 
information based on the solution in [18] and [19]. An example information flow of location verification based on 
access line identifier is provided in Annex B. 

NOTE: The verifying node must receive the IP address as used in the NASS. This may require either that the 
verifying node be located directly at the edge of the NASS, or that the NASS uses public IP addresses 
without NAT or NAPT to Internet. 

8.1 .4 Surrounding macro-cell information provided by H(e)NB 

If the H(e)NB has the capability to receive transmissions from surrounding macro-cells, it shall be capable of providing 
information on the identity of any such macro-cells to the verifying node. 

NOTE: A report that no macro-cells can be detected may be of use in determining that the H(e)NB has been 
moved to an unauthorized location. 

8.1 .5 GNSS information provided by H(e)NB 

If the H(e)NB has the capability to receive GNSS transmissions, it shall be capable of sending GNSS determined 
location information to the verifying node. To be able to determine H(e)NB location based on an internal GNSS, a 
H(e)NB must be equipped with a GNSS receiver and be installed in a location where GNSS satellites can be acquired. 
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8.1.6 Requirements 



The verifying node shall be capable of requesting one or more of the types of location information listed in section 
8.1.1. 

It shall be possible to configure how often the verifying node requests location information, and what information types 
are requested. 

It shall be possible to configure policies to control how the verifying node evaluates the received location information in 
order to perform location verification. 

NOTE: The details of these policies are out of scope of this specification. 

The verifying node may perform location verification using information provided by the H(e)NB. This information may 
be provided automatically and/or upon request. 

It shall be possible for the verifying node to use and optionally store ancillary information to perform location 
verification such as geo-coordinates of surrounding macrocells, postal address of H(e)NB as claimed by H(e)NB 
hosting party, IP address location information, etc. 

It shall be possible for the verifying node to perform location verification both before and after switching on the 
H(e)NB radio. 

Depending on the result of location verification, the verifying node shall take one or more of the following actions: raise 
an alarm, permit the H(e)NB to radiate or prevent the H(e)NB from radiating. 

According to operator policy, an operating H(e)NB which is ordered to cease radiating may do so immediately, or it 
may wait until any calls in progress have been completed before it complies with the order and ceases radiating. It shall 
not allow new calls to be established during this waiting period. 

8.2 Access Control Mechanisms for H(e)NB 

8.2.1 Non-CSG IVIethod 

The ACL (Access Control List) based access control mechanism for a non CSG capable UE accessing the HNB or a UE 
accessing a non CSG capable HNB is handled in [12]. The ACL shall be securely stored in and integrity protected in the 
HNB if the HNB performs access control. 

8.2.2 CSG IVIethod 

The CSG based access control mechanism for a CSG capable UE accessing the CSG capable H(e)NB is handled in 

[12]. 

HSS shall push the latest subscriber's CSG membership list, relevant for the currently used network, to the 
MME/SGSN/VLR. MME/SGSN/VLR shall update the CSG lists on receiving the updated list from the HSS. 

NOTE: In the HSS there is no differentiation required between entries in the Allowed and Operator CSG List, as 
this is relevant for the UE only. 

8.3 Protection of H(e)MS traffic between H(e)MS and H(e)NB 
8.3.1 Connection to H(e)MS accessible on MNO Intranet 

In case that the H(e)MS is accessible on MNO Intranet, H(e)MS traffic shall be protected through the support of one of 
the two security mechanisms determined by the Network Operator"s Security Policies: 

H(e)MS traffic is protected in hop-by-hop way. H(e)MS traffic is protected by the backhaul link between 
H(e)NB and SeGW established according to clause 7.4. Network security mechanisms (cf TS33.210 NDS/IP 
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[9]) shall be used to protect H(e)MS traffic between SeGW and H(e)MS when the path from SeGW to H(e)MS 
is considered as insecure. 

H(e)MS traffic is protected end-to-end between the H(e)NB and the H(e)MS by utilizing TLS tunnel through 
the backhaul link established according to clause 7.4 for additional end-to-end security. 

When TLS is performed between H(e)NB and H(e)MS, mutual authentication between H(e)NB and H(e)MS shall be 
based on device certificate for the H(e)NB and network certificate for the H(e)MS. H(e)NB and H(e)MS may check the 
validity of the certificates as given in sub-clause 8.3.2.1 . 

8.3.2 Connection to H(e)MS accessible on public Internet 
8.3.2.1 General 

In case that the H(e)]VIS is accessible on the public Internet, the H(e)MS is exposed to attackers located in insecure 
network. H(e)MS traffic shall be protected by TLS tunnel established between H(e)NB and H(e)MS. In this case, 
mutual authentication between H(e)NB and H(e)MS shall be based on device certificate for the H(e)NB and network 
certificate for the H(e)MS. The H(e)NB shall verify the H(e)MS identity by checking the subject AltName field of the 
H(e)MS certificate against the name of the H(e)MS. 

NOTE 1: If DNS is available, the H(e)MS"s name is the FQDN used to resolve its IP address; otherwise it is the IP 
address of the H(e)MS. 

The H(e)NB may check the revocation status of the H(e)MS certificate using OCSP as specified in [22] and [23] with 
the exception that the SHA-1 and SHA-256 hash functions shall be mandatory to support. For security reasons, the use 
of SHA-1 is not recommended for newly created OCSP responses. If the profile in [23] is used, support for WAP 
specific protocols is not required, and the provisions on certificates and signatures given in TS 33.310 [7], clause 6.1, 
shall be followed. 

NOTE la: It is likely that in a future 3GPP release, OCSP responses which use SHA-1 as the hash algorithm will be 
prohibited. 

Support for OCSP is optional for the operator network. The H(e)NB should support OCSP. 

NOTE 2: It is strongly recommended to support OCSP in the H(e)NB, as this feature may become mandatory for 
H(e)NB in future releases. 

The OCSP communication between H(e)NB and OCSP server may use the in-band signaling of certificate revocation 
status in TLS according to TLS Extensions as specified in Annex E of TS 33.310 [7]. Support for this extension to TLS 
in H(e)NB and H(e)MS is optional. 

The H(e)MS may check the revocation status of the H(e)NB certificate using CRLs according to TS 33.310 [7] or 
OCSP as specified in [22] and [23] with the exception that the SHA-1 and SHA-256 hash functions shall be mandatory 
to support. For security reasons, the use of SHA-1 is not recommended for newly created CRLs and OCSP responses. If 
the profile in [23] is used, support for WAP specific protocols is not required, and the provisions on certificates and 
signatures given in TS 33.310 [7], clause 6.1, shall be followed. 

NOTE 2a: It is likely that in a future 3GPP release, CRLs and OCSP responses which use SHA-1 as the hash 
algorithm will be prohibited. 

The H(e)MS shall implement support for either CRL checking or OCSP or both. The locations of the CRL Server and 
OCSP Responder may be in the operator's network or provided by the manufacturer/vendor. Neither the operator nor 
the manufacturer is required to provide a CRL Server or an OCSP Responder. For the case when the operator provides 
a CRL Server or OCSP Responder, the manufacturer shall forward revocation data to the operator. The interface to 
forward revocation data is out of scope of the present document. 

If the H(e)NB certificate contains CRL or OCSP server information (cf. sub-clause 8.3.3.1), then the H(e)MS may 
contact this server for revocation information. 

NOTE 3: A CRL or OCSP server located at manufacturer of H(e)NB allows distribution of revocation information 
by the manufacturer directly. To use such revocation information, normally the H(e)MS needs a CRL or 
OCSP client capable to reach the public Internet to contact these servers. 
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Validity check of H(e)NB certificates in H(e)MS shall be configurable by the operator, i.e. whether to use CRLs, OCSP 
or both and whether to use operator CRL or OCSP server, manufacturer CRL or OCSP server, or more than one of 
them. 

8.3.2.2 Device Validation 

The H(e)NB shall support a device validation method whereby the device implicitly indicates its validity to the H(e)MS 
by successful execution of device authentication. To achieve this, the following requirement applies: 

If the device integrity check according to clause 6.1 failed, the TrE shall not give access to the sensitive 
functions using the private key needed for H(e)NB device authentication with the H(e)MS. 

The CA issuing the H(e)NB device certificate need to be trusted by the manufacturer or vendor of the H(e)NB, 
whoever of both is responsible for the device integrity of the H(e)NB. 

NOTE 1: This trust in the CA issuing the device certificate is in addition to the requirements given in clause 5.2. 

NOTE 2: If the H(e)NB is enrolled to an operator PKI, and thus the operator device certificate is used during 
authentication, then also such successful authentication towards SeGW or other network elements 
includes the indication of successful device validation. This transitive trust is possible, as the enrolment 
takes place based on the vendor device certificate. This transition of trust must be considered by the 
operator. 

8.3.3 TLS certificate profile 
8.3.3.1 TLS entity certificates 

The H(e)NB and H(e)MS certificates for use with TLS shall both conform to the requirements set out in clauses 6.1.1 
and 6.1.3a of TS 33.310 [7] with the following additions and exceptions: 

The H(e)NB certificate shall be signed by an entity that is authorized by the operator, e.g. the manufacturer or 
the vendor. In addition, the entity signing the H(e)NB certificate shall be authorized by the manufacturer or 
vendor. 

The H(e)NB certificate shall carry the HNB unique identity in FQDN format, as specified in TS 23.003 [8], in 
both the subjectAltName extension of type dNSName and in the common name field. 

If the manufacturer or vendor provides a CRL or OCSP server, the H(e)NB certificate shall carry the CRL 
distribution point as specified in TS 33.310 [7] or the OCSP server information (AIA extension) as specified in 
RFC 5280 [26] and RFC 2560 [22]. 

NOTE 1 : Server information for CRL and/or OCSP servers deployed in operator network may be configured in 
H(e)MS. 

The H(e)MS certificate shall carry the identity of the H(e)MS in FQDN format in both the subjectAltName 
extension of type dNSName and in the common name field. 

NOTE 2: The reason for carrying the identities in the common name field is compatibility. 

If an OCSP server is provided for the H(e)MS certificates, the H(e)MS certificate shall carry the OCSP server 
information as specified in RFC 2560 [22]. This OCSP server information is not mandatory, if OCSP extension 
to TLS according to TLS Extensions as specified in Annex E of TS 33.310 [7] is used. 

NOTE 3: In general, it is possible to use a TLS client certificate in accordance with this specification also for 

IKEv2, if key exchange algorithm and used key length for both TLS and IKEv2 are chosen identically. 

NOTE 4: Methods for securely updating the TLS client certificate remotely are handled in the present document 
only for the case when enrolment to an operator PKI is supported and used. If it is not possible to update 
the TLS client certificate, the certificate lifetime needs to exceed the expected lifetime of the H(e)NB. 

If the H(e)NB is enrolled to an operator PKI, the H(e)NB certificate issued by the operator CA and the H(e)NB 
device identity assigned by the operator may follow clause 6.1.3a of TS 33.310 [7] without additions and 
exceptions. 
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8.3.3.2 TLS CA certificates 

TLS CA certificates shall conform to the requirements set out in clauses 6.1.1 and 6.1.4a of TS 33.310 [7] with the 
exception that there is no restriction in the issuer name. 

8.3.4 TR-069 protocol profile 

For the management of the H(e)NB by the H(e)MS, the CPE WAN Management Protocol TR-069 [15] shall be used 
with the following restrictions and extensions: 

The TLS profile specified in TS 33.310 [7], Annex E, shall apply. 

Shared-secret-based authentication between H(e)NB acting as CPE and H(e)MS acting as ACS shall not be 
allowed. Only certificate-based authentication shall be allowed. 

The use of TLS to transport the CPE WAN Management Protocol shall be mandatory in case that the H(e)MS is 
accessible on public internet or when TLS is used within the IPsec tunnel. 

The H(e)MS URI shall be specified as an HTTPS URL in case that the H(e)MS is accessible on public internet 
or when TLS is used within the IPsec tunnel. 

- Ciphersuites with RC4 shall not be used. The support of TLS cipher suite RSA_WITH_RC4_128_SHA shall not 
be mandatory 

The H(e)NB acting as CPE shall not be obliged to wait until it has accurate absolute time before it contacts the 
H(e)MS acting as ACS. 

NOTE 1: The term "absolute time" refers to UTC and its use is consistent with its definition and use in the sections 
on "Use of SSL/TLS and TCP and on Data Types" in TR-069 [15]. 

If the H(e)NB contacts the H(e)MS without having the accurate absolute time, it shall not ignore components of 
the H(e)MS certificate related to absolute time, e.g. not-valid-before and not-valid-after certificate restrictions, 
but use the local clock set according to the procedure on restoration of power specified in clause 6.3.1 of the 
present document. 

The support for H(e)NB authentication using client-side (CPE side) certificates shall be mandatory. 

- The H(e)NB acting as CPE shall be authenticated to the H(e)MS by the H(e)NB identity contained in the 
H(e)NB certificate in case that mutual authentication between H(e)NB and H(e)MS is performed. The exact 
format of the TLS client certificate is specified in clause 8.3.3.1. 

8.4 Protection of SW Download 

The H(e)NB shall utilize the established TR-069 method to download software from the H(e)MS or a server directed to 
by the H(e)MS according to TR-069 Version 1 Amendment 2 [15]. The following requirements are added for security: 

The file shall use the signed package format according to TR-069 [15]. 

NOTE 1: Depending on the link to H(e)MS, transport security is provided by the secure link according to clauses 
4.3.1 (when H(e)MS is in operator network) or 4.3.2 (when H(e)MS is in public Internet). 

The SignedData object in the signed package shall contain at least one signature provided by a software signing 
entity, with certificate issued by an operator trusted CA. 

The TrE shall use a public key issued by an operator trusted CA to verify the software signing entity certificate 
and the signature(s) in the SignedData object. If the verification fails, the H(e)NB shall delete and not install the 
software that failed the verification. All root certificates used for this purpose shall be stored in the TrE. 

NOTE 2: Notification of this failure is according to procedures in TR-069 [15]. 

The signed package shall also contain the trusted reference values needed for the software integrity checks 
performed during secure boot.. 
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NOTE 3: TR-069 [15] supports multiple signatures which can be used for the purpose of supporting different hash 
algorithms. 

8.5 Enrolment of H(e)NB to an Operator PKI 

8.5.1 General 

For certain use cases it is advantageous to authenticate the H(e)NB with a device identity and a device certificate issued 
by the operator. For such cases an automatic enrolment of H(e)NBs to an operator PKI is specified based on device 
authentication using a vendor device certificate. 

Support and usage of enrolment of a H(e)NB to an operator PKI is optional. 

If the establishment of direct links between H(e)NBs according to clause 4.3.4 is is supported, then support of 
enrolment according to the clause 8.5 is mandatory. 

8.5.2 Enrolment Procedure 

The enrolment procedure to an operator PKI shall follow clause 9 of TS 33.310 [7] with the following additions and 
exceptions: 

The H(e)NB shall be pre-provisioned with the operator root CA certificate before the start of the procedure 
specified in clause 9 of TS 33.310 [7]. 

NOTE 1: The operator root CA certificate may be provisioned e.g. by pre-provisioning by the manufacturer/vendor 
or by a management procedure from an initial H(e)MS accessed using a vendor device certificate for 
authentication. 

The vendor device certificate used for enrolment (and the certificate chain up to the root certificate of the vendor 
certificate) shall either follow the rules given in clause 9.4 of TS 33.310 [7] or the rules given in clause 7.2.5.2 of 
the present document. 

NOTE 2: The enrolment procedure may take place with a RA/CA accessible on the public Internet or via a SeGW 
with a RA/CA accessible on the MNO Intranet. In the latter case the SeGW has to accept a vendor device 
certificate for enrolment connection, even though the operator device certificate is used later by the 
SeGW on establishment of the operational backhaul link. 

8.5.3 Certificate Validation 

If enrolment to an operator PKI is supported, the H(e)NB may check the revocation status of certificates using CRLs 
according to TS 33.310 [7]. 

NOTE: Certificate validation using CRLs is the normal method specified in TS 33.310 [7] in conjunction with 
operator-provided certificates. Thus all H(e)NBs supporting operator PKI enrolment should also support 
CRLs. 
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9 Security Aspects of Emergency Call Handling 

The H(e)NB and/or the H(e)NB-GW shall support security handling of Emergency call as specified in TS 25.467[12], 
TS 33.102 [20] andTS 33.401 [21]. 

Emergency call shall be allowed by the H(e)NB and/or operator"s radio access or core network entities (e.g. H(e)NB- 
GW) regardless of whether UE can pass access control as specified in clauses 5.4 and 8.2. 

In case of non CSG UEs or non CSG HNBs, after Emergency call is finished, the context (as described in TS 25.467 
[12]) established between the HNB and operator"s access or core network entities for UEs who can not get access over 
the HNB shall be released to prevent the UE from accessing non-emergency services. 

NOTE: In case of non CSG UEs or non CSG HNBs, a UE could establish a RRC connection for an emergency 
call in order to skip the mandatory access control and could then try to make an unauthorized normal call 
afterwards. In order to alleviate that security risk the HNB-GW may check locally the consistency of all 
messages related to the registration for and establishment of an emergency call. 
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1 Security Aspects for Mobility 
10.1 Inbound mobility 

In mobility from macro NB or HNB towards HNB CSG/hybrid, access control or membership verification for CSG 
capable UE and non CSG capable UE shall be performed as described in [12]. 

Key management is done in core network as described in [20]. 

Access control or membership verification for UE in mobility from macro eNB or HeNB towards HeNB CSG/hybrid is 
handled in mobility scenario in [27]. 

Key handling shall follow that in [21]. 



10.2 Outbound mobility 



For mobility from HNB, the normal procedure can be appUed as stated in [28]. Key handling shall follow the macro 
mobility procedure. 

For mobility from HeNB, the normal procedure can be applied as stated in [27]. Key handling shall follow the macro 
mobility procedure. 
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1 1 Security Procedures for Direct Interfaces between 
Base Stations 

11.1 General 

For all security features specified in clause 1 1 the usage of operator certificates is required. Thus in the context of clause 
1 1 the support of enrolment according to clause 8.5 of the present document is mandatory. 

11.2 Direct Link between two H(e)NBs 

The security procedures specified in the present subclause apply to the lurh interface between two HNBs as specified in 
TS 25.467 [12] and the X2 interface between two HeNBs as specified in TS 36.300 [27]. 

The security procedures specified in the present subclause are mandatory to support if direct links for lurh or X2 
interfaces as specified in clause 4.3.4 of the present document are supported. The usage of the security procedures shall 
depend on operator policy. 

NOTE 1 : In particular in enterprise deployment case, the operator may consider the enterprise IP infrastructure as 
trustworthy, and may waive the usage the security procedures. 

The security procedures on the direct link between two H(e)NBs shall follow the procedure given in clauses 7.2 and 7.4 
of the present document. The H(e)NB both as IKEv2 initiator and responder shall perform the handling of the certificate 
of the other party in the same way as the handling of the SeGW certificate given in clause 7.2.2. 

NOTE 2: The usage of OCSP in-band signaling of certificate revocation status in IKEv2 according to RFC 4806 

[24] (cf. clause 7.2.2) may not be applicable, as in this case the responding H(e)NB would have to contact 
the OCSP server, 

NOTE 3: CRL or OCSP messages may be carried within the backhaul link between H(e)NB and SeGW. 

NOTE 4: Allocation of remote (i.e. inner) IP addresses (cf. clause 7.4) during IKEv2 is not relevant for the 
establishment of the direct link. 
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Annex A (informative): 
Authentication Call-flows 

A.1 Device Authentication Call-flow Example 

Certificate based mutual authentication between the H(e)NB and the core network is specified in clause 7.2. As example 
the call flow between the H(e)NB and the SeGW is shown in Figure A.l. This example illustrates an autonomous 
device integrity check followed by initiation of device authentication between H(e)NB and SeGW. Also this example 
illustrates H(e)NB and L-GW IP address assignments via the IKEv2 CFG payload. 



H(e)NB 
1 

1 . Secure Boot and Device Integrity 



SeGW 



2. IKE_SA_INIT request_ 
HDR, SA, KE, Ni 



3. 1 KE_SA_I NIT response 
HDR, SA, KE, Nr, CERTREQ 



4. IKE_AUTH request 

-HDR, SK{IDi, CERT, CERTREQ, AUTH, [N(INTEGRITY_INFO)],- 

GP(GFG_REQUEST), SA, TSi, TSr, } 



7. IKE-AUTH response 
-HDR SK{IDr, CERT, AUTH, CP(CFG_REPL'Y); 
SA, TSi, TSr} 



5. Verify H(e)NB's certificate 

I 

6. SeGW processes N payload 



8. Verify SeGWs certificate 



9. Delete old IKE SA 



Figure A.l : Certificate-based authentication with device integrity 

1 . TrE brings H(e)NB to secure boot and performs device integrity check of H(e)NB. 
NOTE 1 : If the device integrity check fails the following procedure is not executed. 

2. Following successful device integrity check, the H(e)NB sends an IKE_SA_INIT request to the SeGW. 

3. The SeGW sends IKE_SA_INIT response, requesting a certificate from the H(e)NB. 

4. The H(e)NB sends its identity in the IDi payload in this first message of the IKE_AUTH phase, and begins 
negotiation of child security associations. Optionally a user profile may be selected based on the H(e)NB"s 
identity presented in the IDi payload and the authentication type indication in the user profile may be used to 
enforce the choice of authentication (device only or combined device and HP). The H(e)NB sends the AUTH 
payload and its own certificate, and also requests a certificate from the SeGW. Configuration payload is carried 
in this message if the H(e)NB"s and/or L-GW"s remote IP address(es) should be configured dynamically. 
H(e)NB optionally includes a Notify Payload containing integrity information of H(e)NB with a Notification 
Type of INTEGRITY_INFO in the IKE_AUTH request. Computation of the AUTH parameter is performed 
within the H(e)NB"s TrE. If configured to check the validity of the SeGW certificate the H(e)NB retrieves 
SeGW certificate status information from the OCSP responder. Alternatively the H(e)NB may add an OCSP 
request to the IKE message. 

NOTE 2: Inclusion of the Notify Payload and further usage of data transferred in this payload is not part of 
autonomous validation. 

5. The SeGW checks the correctness of the AUTH received from the H(e)NB and calculates the AUTH parameter 
which authenticates the second IKE_SA_INIT message. The SeGW verifies the certificate received from the 
H(e)NB. The SeGW may check the vaUdity of the certificates using CRL or OCSP. If the H(e)NB request 
contained an OCSP request, or if the SeGW is configured to provide its certification revocation status to the 
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H(e)NB, the SeGW retrieves SeGW certificate status information from the OCSP server, or uses a valid cached 
response if one is available 

6. The SeGW processes the N payload of the IKE_AUTH request based on local policy of the operator. 

NOTE 3: SeGW may choose to retain the information carried in the N payload for statistical analysis, send the 

information to a FIGS (Fraud Information Gathering System) for fraud detection, or send the information 
to a validation entity for validation. 

7. The SeGW sends its identity in the IDr payload, the AUTH parameter and its certificate to the H(e)NB together 
with the configuration payload, security associations, and the rest of the IKEv2 parameters and the IKEv2 
negotiation terminates. The Remote IP address(es) is (are) assigned in the configuration payload (CFG_REPLY), 
if the H(e)NB requested for H(e)NB"s and/or L-GW"s Remote IP address(es) through the CFG_REQUEST. If 
the SeGW allocates different remote IP addresses to the H(e)NB and the L-GW, then the SeGW can include 
information to differentiate the IP address assigned to the H(e)NB and the L-GW, in order to avoid any 
misconfiguration. A possible mechanism to inform which IP address is to be used for H(e)NB or L-GW is 
implementation specific and out of scope of the present document. If the SeGW has SeGW certificate status 
information available, this information is added to the IKE response to H(e)NB. 

8. The H(e)NB verifies the SeGW certificate with its stored root certificate. The root certificate for the SeGW 
certificate shall be stored in the TrE. The H(e)NB checks that the SeGW identity as contained in the SeGW 
certificate equals the SeGW identity as provided to H(e)NB by initial configuration or by H(e)MS. The H(e)NB 
checks the validity of the SeGW certificates using the OCSP response if configured to do so. 

9. If the SeGW detects that an old IKE SA for that H(e)NB already exists, it will delete the IKE SA and send the 
H(e)NB an INFORMATIONAL exchange with a Delete payload in order to delete the old IKE SA in H(e)NB. 

NOTE 4: If the Notify Payload is used to convey integrity information, then an available values in the Private Use 
Status Types range of Notification Type values in IKEv2 may be used. In case the integrity information 
payload carries security information, security mechanisms have to be used. The detailed security 
mechanisms are out of scope of present document. 



A.2 Combined Device and HP Authentication Call-flow 
Example 

The certificate based mutual authentication between the H(e)NB and the core network, followed by an EAP-AKA- 
based HP authentication exchange between the H(e)NB/HPM and the AAA server, is specified in clause 7.2. As 
example the call flow between the H(e)NB, SeGW and AAA server is shown in Figure A.2. This example illustrates an 
autonomous device integrity check followed by initiation of combined device and HP authentication. Also this example 
illustrates H(e)NB and L-GW IP address assignments via IKEv2 CFG payload 
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UE 



H(e)NB 



SeGW 



1. secure boot and device integrity 



2. IKE_SA_INIT request 

HDR, SA, KE, Ni 

3. IKE_SA_INIT response 

HDR, SA, KE, Nr, CERTREQ, 

N(MULTIPLE_AUTH_SUPPORTED) 

4. IKE_AUTH request 

HDR, SK{IDi, IDr, CERT, CERTREQ, AUTH, 

CP(CFG_REQUEST),SA, TSi, TSr, 

N(MULTIPLE_AUTH_SUPPORTED), 

N(ANOTHER_AUTH_FOLLOWS)) 



AAA-Sei^er 



_ 6. IKE_AUTH response 
"HDR SK{IDr, AUTH, CERT)" 



5. Verify H(e)NB's certificate 



7. Verify SGW's certificate 



8. IKE_AUTH request _ 
HDR, SK(IDi=NAI[, IDr])} 



12. IKE_AUTH response _ 

HDR SK{EAP-Requesl/AKA-Challenge (RAND, AUTN)} 



13. Verify AKA parameters 



14. IKE_AUTH request 



HDR SK{EAP-Response/AKA-Cliallenge (RES)) 



_ 9. Access-Request 

(EAP-Response/ldentity(NAI)) 

1 1 . Access-Challenge 

-[EAP-Request/AKA-Challenge]— 

(RAND, AUTN) 



1 5. Access-Request 
-[EAP-Response/AKA-Challenge] — 

(RES) 
1 6. Access-Accept _ 

(MSK, [TiA,] EAP-Success] 



19. Verify AKA parameters 



1 8. IKE_AUTH response_ 
"HDR SK{EAP-Success} 



20. IKE_AUTH request_ 
HDR SK{AUTH} 



17. AUTH payload is calculated by 
key material 



21. IKE-AUTH response _ 

HDR SK{AUTH, CP(CFG_REPLY), SA, TSi, TSr} 



22. Delete old IKE SA 



HSS 



- 1 0. AV retrieval if needed— 



Figure A.2: Combined certificate and EAP-AKA-based authentication 

1 . TrE brings H(e)NB to secure boot and performs device integrity check of H(e)NB. 
NOTE: If the device integrity check fails the following procedure is not executed. 

2. Following successful device integrity check, the H(e)NB sends an IKE_SA_INIT request to the SeGW. 

3. The SeGW sends IKE_SA_INIT response, requesting a certificate from the H(e)NB. The SeGW indicates that 
it support Multiple Authentication by including the MULTIPLE. AUTH_SUPPORTED payload. 

4. The H(e)NB inserts its identity in the IDi payload in this first message of the IKE_AUTH phase, computes the 
AUTH parameter within its TrE, and begins negotiation of child security associations. The authentication type 
indication in user profile which is selected selected by H(e)NB"s identity presented in the IDi payload may be 
used and enforce the choice of authentication (device only or combined device and HP). The H(e)NB then sends 
IKE_AUTH request with the AUTH payload, its own certificate, and also requests a certificate from the SeGW. 
Configuration payload is carried in this message if the H(e)NB"s and/or L-GW"s remote IP address(es) should 
be configured dynamically. The H(e)NB indicates that it support Multiple Authentication and that it wants to do 
a second authentication by including the MULTIPLE. AUTH_SUPPORTED and 

ANOTHER. AUTH_FOLLOWS attributes. If configured to check the validity of the SeGW certificate the 
H(e)NB retrieves SeGW certificate status information from the OCSP responder. Alternatively the H(e)NB may 
add an OCSP request to the IKE message. 

5. The SeGW checks the correctness of the AUTH received from the H(e)NB and calculates the AUTH parameter 
which authenticates the second IKE_SA_INIT message. The SeGW verifies the certificate received from the 
H(e)NB. The SeGW may check the validity of the certificates using CRL or OCSP. If the H(e)NB request 
contained an OCSP request, or if the SeGW is configured to provide its certification revocation status to the 
H(e)NB, the SeGW retrieves SeGW certificate status information from the OCSP server, or uses a valid cached 
response if one is available. 
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6. The SeGW sends IKE_AUTH response with its identity in the IDr payload, the AUTH parameter and its 
certificate to the H(e)NB. If the SeGW has SeGW certificate status information available, this information is 
added to the IKE response to H(e)NB. 

7. The H(e)NB verifies the SeGW certificate with its stored root certificate. The root certificate for the SeGW 
certificate shall be stored in the TrE. The H(e)NB checks that the SeGW identity as contained in the SeGW 
certificate equals the SeGW identity as provided to H(e)NB by initial configuration or by H(e)MS. The H(e)NB 
checks the validity of the SeGW certificates using the OCSP response if configured to do so. 

8. The H(e)NB sends another IKE_AUTH request message with the HP"s identity in the IDi payload and the 
AUTH payload omitted to inform the SeGW that the H(e)NB want to perform EAP authentication. 

9. The SeGW sends the Authentication Request message with an empty EAP AVP to the 3GPP AAA Server, 
containing the identity received in IKE_AUTH request message received in step 8. 

10. The AAA Server shall fetch the subscription data and authentication vectors from HSS/HLR. 

1 1 . The AAA Server initiates the authentication challenge. 

12. The SeGW sends IKE_AUTH response to H(e)NB. The EAP message received from the AAA Server (EAP- 
Request/AKA-Challenge) is included in order to start the EAP procedure over IKEv2. 

13. The H(e)NB processes the EAP challenge message and uses the HPM for verification of the AUTN and 
generating the RES parameters. Optionally, processing of the whole EAP challenge message, including 
verification of the received MAC with the newly derived keying material may be performed within the 
H(e)NB"s HPM. 

14. The H(e)NB sends the IKE_AUTH request with the EAP-Response/AKA-Challenge to the SeGW. 

15. The SeGW forwards the EAP-Response/AKA-Challenge message to the AAA Server. 

16. When all checks are successful, the AAA Server sends the Authentication Answer including an EAP success and 
the key material to the SeGW. This key material should consist of the MSK generated during the authentication 
process. 

17. The EAP Success message is forwarded to the H(e)NB over IKEv2 in IKE_AUTH response. 

18 The H(e)NB takes its own copy of the MSK as input to generate the AUTH parameter to authenticate the first 
IKE_SA_INIT message. Optionally the computation of the AUTH parameter is performed within the H(e)NB"s 
HPM. 

19. IKE_AUTH request with the AUTH parameter is sent to the SeGW. 

20. The MSK received in step 16 is used by the SeGW to generate the AUTH parameters in order to authenticate the 
IKE_SA_INIT phase messages. 

21. The SeGW checks the correctness of the AUTH received from the H(e)NB. The SeGW should send the assigned 
Remote IP address in the configuration payload (CFG_REPLY), if the H(e)NB requested for H(e)NB"s and/or 
L-GW"s Remote IP address through the CFG_REQUEST. If the SeGW allocates different remote IP addresses 
to the L-GW and to the H(e)NB, then the SeGW can include information to differentiate the IP address 
assigned to the H(e)NB and the L-GW, in order to avoid any misconfiguration.A possible mechanism to inform 
which IP address is to be used for H(e)NB or L-GW is implementation specific and out of scope of the present 
document. Then the IKE_AUTH response with AUTH parameter is sent to the H(e)NB together with the 
configuration payload, security associations and the rest of the IKEv2 parameters and the IKEv2 negotiation 
terminates. 

22. If the SeGW detects that an old IKE S A for that H(e)NB already exists, it will delete the IKE S A and send the 
H(e)NB an INFORMATIONAL exchange with a Delete payload in order to delete the old IKE SA in H(e)NB. 
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Annex B (informative): 
Location Verification Examples 

B.1 Example of Location verification based on IP address 
and line identifier in MASS 

The NASS (Network Attachment Subsystem) standard in TISPAN [18] has defined the interface through which the 
mobile core network is able to query the geographic location information based on the IP address. The network-based 
database can be the CLF (connectivity Session Location and Repository Function) element . The CLP registers the 
following information provided by the NACF (network access configuration function ), and make them relevant: the IP 
address located to the fixed access point, the network location information, and geography location information. The 
CLF provides e2 interface for service layer entity. The reference document [19] specifies e2 interface based on 
Diameter protocol. 

NOTE 1: The verifying node must receive the IP address as used in the NASS. This may require either that the 
verifying node be located directly at the edge of the NASS, or that the NASS uses public IP addresses 
without NAT or NAPT to Internet. 

The entity used to query CLF is located in the verifying node. 

The contract location exists in the verifying node already before the location verification process can be performed. The 
contract location can be defined by the operator when H(e)NB service is subscribed to the network. 

The location authentication procedure consists of the following steps: 

a) H(e)NB sends request message to the verifying node, carrying its IP address in this message. 

b) According to the IP address, the verifying node queries the CLF to obtain the access line location identifier. 

c) Verifying node authenticates whether the access line location identifier stored in the verifying node (i.e. the legal 
contract location) corresponds to the location identifier it retrieves from the CLF based on IP address obtained 
from the H(e)NB. If it is the same, this means that the H(e)NB location has not been changed. 

d) Other procedures, e.g. provisioning of configuration parameters from the verifying node to the H(e)NB, can be 
performed only after successful location verification of the H(e)NB by the verifying node. 

NOTE 2: Storage of the location information in the verifying node as a subscription profile is preferable. 

NOTE 3 : The above procedure provides an effective method to query the CLF according the H(e)NB"s IP address. 
If the CLF is not available to the mobile operator, similar methods using the broadband connection 
information can be implemented. 



B.2 Example process of location verification when the 
verifying node receive different types of location 
information 

1 . Different types of H(e)NB location identifiers corresponding to the location of H(e)NB are stored in verifying 

node or CLF. 

2. Upon obtaining new location information from H(e)NB, verifying node should verify the new location 

information by the stored different types of location identifiers or query the CLF for the corresponding location 
identifiers . If all of the new location information is verified successfully, it means the location of H(e)NB is not 
changed. Or else, verifying node or the CLF should re-register the new location identifiers corresponding to the 
new location information of the H(e)NB on condition that the availability of the new location information is 
verified by the operators. 
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3. Other procedures, e.g. provisioning of configuration parameters from the verifying node to the H(e)NB, can be 
performed only after successful location verification of the H(e)NB by the verifying node. 

NOTE: This example assumes that a TISPAN NASS may be deployed using the CLF as a location information 
storage node as described in [18]. 
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